home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 5054 < prev    next >
Encoding:
Text File  |  1996-08-05  |  6.4 KB  |  134 lines
  1. Newsgroups: comp.lang.misc,comp.lang.perl.misc,comp.lang.tcl,comp.lang.c,comp.lang.java
  2. Path: hearst.acc.Virginia.EDU!murdoch!usenet
  3. From: jtv2j@mamba.cs.virginia.edu (John Viega)
  4. Subject: Re: Relative Speed of Perl vs. Tcl vs. C
  5. In-Reply-To: Tom Christiansen's message of 11 Feb 1996 21:14:47 GMT
  6. X-Nntp-Posting-Host: mamba-fo.cs.virginia.edu
  7. Message-ID: <JTV2J.96Feb12141108@mamba.cs.virginia.edu>
  8. Sender: usenet@murdoch.acc.Virginia.EDU
  9. Reply-To: rust@Virginia.EDU
  10. Organization: Computer Science Dept, University of Virginia
  11. References: <4e3a2u$eoa@wcap.centerline.com> <JTV2J.96Feb9185929@garnet.cs.virginia.edu>
  12.     <DMKsD6.IEt@da_vinci.ecte.uswc.uswest.com>
  13.     <JTV2J.96Feb11115145@brunelleschi.cs.virginia.edu>
  14.     <4flm87$m0c@csnews.cs.colorado.edu>
  15. Date: Mon, 12 Feb 1996 19:11:08 GMT
  16.  
  17. From: jtv2j (John Viega)
  18. To: Tom Christiansen <tchrist@mox.perl.com>
  19. Subject: Re: Relative Speed of Perl vs. Tcl vs. C
  20. Date: Sun, 11 Feb 96 19:07:36 EST
  21.  
  22. Tom Christiansen writes:
  23.  | In comp.lang.perl.misc, rust@Virginia.EDU writes:
  24.  | :I fell in love with Perl a couple of years ago, until I learned
  25.  | :Python, which can do everything Perl can, and has the advantage of
  26.  | :being readable.  
  27.  | 
  28.  | So many false assumptions in such short text.
  29.  
  30. I think it's all a matter of perspective.  I could say the same thing
  31. about your post, of course, but I won't.  Such vague pot-shots might
  32. help sway people toward your view without considering the arguments
  33. for and against, but, having read the full text of your reply, I don't
  34. believe I've made too many assumptions, never mind any out-and-out
  35. false ones.  The issues at hand are much more a matter of opinion
  36. than of facts that can be proven false.
  37.  
  38.  | 
  39.  | First of all, any language can do anything any other language can do --
  40.  | it's just a ``simple matter of programming''.  Some things are better
  41. Granted.
  42.  
  43.  | supported in the language or libraries than others, but the determined
  44.  | programmer can bend any language to his will.  That being said, Perl's
  45.  | string-processing facilities make Python's seem like mere ed-compatible
  46.  | patterns.  [Examples available upon request.]  Sure, you could eventually
  47.  | write the same in any language, but it would take so much more work that
  48.  | it would seldom be worth it.
  49. Like I said, I've used both languages extensively. Perl's string
  50. processing facilities are more concise than Python's.  However, I
  51. know a lot of people, myself included, who feel that Perl's
  52. conciseness in this area is a drawback.  Sure, it might be 3 to 5
  53. lines of python code, but the operations are a lot clearer.  Besides,
  54. if I want to do string processing, I'm probably going to go use Icon,
  55. anyway... Perl isn't everyone's favorite choice for string handling.
  56.  
  57.  | 
  58.  | Second of all, the legibility thing is a red herring.  If I showed someone
  59.  | the obfuscated C programming contest entries -- or even some freshman
  60.  | college students muddled attempts at C programs -- they would likely decry
  61.  | C as inherently illegible.  That's silly.  A bad programmer (or a sneaky
  62.  | one) can always write programs that are hard to read, and a good
  63.  | programmer can always write ones easy to read.  The implementation
  64.  | language here is largely irrelevant.  If you don't write perlstyle(1)
  65.  | compliant Perl code, it's not the language's fault that you have bad
  66.  | taste.
  67.  
  68. I agree with you on most of this, but not quite all of it.  I think it
  69. is unfortunate that people believe that legibility should not be an
  70. issue in language design.  Like you say, most languages enable someone
  71. who is set on writing a legible program to do so. While most languages
  72. don't have much to say on style, they certainly could support legible
  73. style, instead of merely enabling it.  Some languages make it a lot
  74. easier than others.  Having non-obvious operators such as many of
  75. Perl's, and having type qualifiers are variable prefixes make for less
  76. legible programs in _some people's minds_.  Legibility is highly
  77. subjective without a doubt, but a lot of people seem to agree that
  78. Python is inherently more readable than Perl.  If 10 rewrote all of
  79. the examples from Programming Perl in Python, I'll bet most people who
  80. don't know either language, and a large number of the people who know
  81. Perl and not Python would be able to understand the Python version
  82. much easier, because the structure of the language forces at least a
  83. small amount of structure, and directly supports a lot more.
  84.  
  85.  
  86.  | 
  87.  | As for whether a language should be understandable to programmers not 
  88.  | even passingly conversant in that language, that's a theoretical matter
  89.  | upon which the jury is yet to return.  I tend to prefer to see professional
  90.  | tools tailored for professional use. 
  91. I tend to prefer to see professional tools that enables professional
  92. use., with which a novice can instantly be productive.  I believe there is no
  93. excuse for any programming system to do any less, especially if it
  94. wants a user base.
  95.  
  96.  |  It's easy to make a system that  
  97.  | people with no training to use -- but very hard to make it so that experts
  98.  | also feel comfortable with.  
  99.  
  100. I think the user interface / usability engineering community would
  101. strongly disagree with you.  Making easy-to-use interfaces isn't easy.
  102. Take doors, for example.  We've been building them for how long?  And
  103. yet, how often do you push on a door that was meant to be pulled?
  104. The user interface community has good guidelines to give as to how to
  105. make a system easier to use for both novices and experts, at the same
  106. time, even.  I'd strongly recommend the following books:
  107.  
  108. Jakob Nielson's "Usability Engineering"
  109. Don Norman's  "The Design of Everyday Things"
  110.  
  111.  | Remember: user-friendly is a politically 
  112.  | correct term for user-obsequious, or sometimes even expert-hostile.
  113. In fact, the user interface / usability community berate the term
  114. "user-friendly" quite harshly.
  115.  
  116.  | If you're merely going to claim that Python or Java are more readable due
  117.  | to weak string-handling, I don't see that as particularly advantageous.
  118.  
  119. I don't claim Java is even more readable ;-)
  120.  
  121. Cheers,
  122.  
  123. John
  124.  
  125. ------------------------------------------------------------------------------|
  126. |John Viega                          "Non-structurally equivolent types in C |
  127. |rust@virginia.edu                     are polymorphic vis-a-vis their common |
  128. |http://www.cs.virginia.edu/~jtv2j/    entity, the core dump."                |
  129. |University of Virginia                                  --George Williams    |
  130. -------------------------------------------------------------------------------
  131.  
  132.  
  133.  
  134.